ShareWare OnLine 2

home *** CD-ROM | disk | FTP | other *** search

/ ShareWare OnLine 2 / ShareWare OnLine Volume 2 (CMS Software)(1993).iso / bbs_soft / jdrbbs08.zip / DOCS_ETC.ZIP / DOCS_2.DOC < prev next >

Wrap

Text File | 1993-04-06 | 169KB | 3,053 lines

JDR_BBS .08 by John Rohner CONTENTS Line Topic ──── ─────────────────────────────────────────────────────── 74 CUSTOMIZING 201 110 ANSI'S 272 ANSI Codes 372 LINES.TXT 437 SHORT.TXT 469 BLOCKS.TXT 497 SECURITY LEVELS 534 Ghosting 578 SYSOPS 590 FILE AREAS 732 Menus 813 Diagrammed File Options 911 Files In Area 925 Misc. 971 MESSAGE AREAS 1035 Menus 1047 PEER REVIEW 1096 WAITING FOR CALLER SCREEN 1185 SENDTT 1222 DATABASER 1233 BLOCKS.TXT DataBaser Structure 1405 Calling Via Menus 1416 Modifying 1419 Deleting 1438 More 1604 DIRECTRY'S 1706 USER HELP 1722 THE "WHO'S ON" STATUS LINE 1759 VOTING 1839 PSEUDO-AI 1851 ACCOUNT VALUE 1872 LIFE & DEATH DELETE 1907 FILE MANAGEMENT 1927 DOORS 1934 Defining 2030 Calling 2112 Executing 2181 Time Maintenance 2216 Misc. 2237 PROTOCOLS 2393 EVENTS 2406 NETMAIL AND ECHOMAIL 2409 Overview 2470 NetMail 2492 EchoMail 2560 FidoNet 2588 Hubs 2617 Costs 2635 Misc. 2670 Commands 2725 Not Ready 2744 MULTI-NODE/MULTITASKING OPERATIONS 2788 INTERNAL NETS 2824 FILE CORRUPTION 2852 TROUBLE-SHOOTING 2893 PERFORMANCE ENHANCEMENTS 2959 REGISTERED PACKAGE 2972 DataBaser 2974 Net Mail File Transfers 2988 Sysops Package 3051 NEXT CUSTOMIZING When designing your BBS, there are three things you primarily 201 change: the menus (commands), the ANSI's, and the text. You use McEditor to change the menu commands. Designing your own commands or just moving around what is there. You use TheDraw, or some other ANSI drawing program, to design your ANSI's. Your ANSI's are the primary "look" of a BBS. You use LINES.TXT (and to a lesser extent BLOCKS.TXT and SHORT.TXT) to change the text that is displayed. You have complete control over all text. The words you choose provide the "feel" of a BBS. To change the text to a foreign language, change BLOCKS.TXT and LINES.TXT. Then upload a copy to me, and I will include it in the next release. For real language conversion, you should also convert your ANSI's. Just dump all the files into, say, NODE.002. This means that you must have language- dependent phone lines, in a future release I'll add a language menu to let users select between node's. I strongly recommend that you do not change the sysop menu or its ANSI's. The sysop menu (and its sub-menus) is actually its own system--with the bottom 6 lines being a "window" for routines to use. These menus will probably change with each release. The single key to turn the BBS "on" is to change the comm port in "Change Settings", to something besides zero (like 1 for COM1:). Answer "N" to the "Null port?" question. You will need to already have the fossil installed and defined in your CONFIG.SYS. ANSI'S All ANSI files may contain special "smart codes". These codes, when encountered, will be replaced by something (see below). Smart codes take the form: xx<<yy, xx>>yy, xx><yy Where "xx" is a number from 1 to whatever. Where "yy" is a number from 0 to whatever. Where "<<" means that the text corresponding to "xx" should be left justified in a space of "yy" characters. Where ">>" means that the text corresponding to "xx" should be right justified in a space of "yy" characters. Where "><" means that the text corresponding to "xx" should be centered in a space of "yy" characters. A "yy" of "0" means to "use whatever comes naturally"--no squeezing if "yy" is too small, no extra spaces to fill up to "yy". By the way, the "" can be gotten in PC-Write with <alt>K, I do not know what this is for other text editors. Below is a listing of what the various "xx" numbers produce: 1 User's full name/company name. Name cased. 2 User's password/verification. 3 User's city & state/location. Name cased. 4 User's home/voice phone number. 5 User's BBS/data phone number. 6 User's birth date. dd-mmm-yy. 7 User's show security level value. 8 User's date they first called. dd-mmm-yy. 9 User's selected file transfer protocol. 1 character. 10 User's subscription start date. dd-mmm-yy. 11 User's subscription end date. dd-mmm-yy. 12 User's subscription type. 1 character. 13 User's available/unused monies sent. 14 User's total monies ever sent. 15 User's date of last call. dd-mmm-yy. 16 User's logons until must change their password. 17 User's date of last changing a L&D value. dd-mmm-yy. 18 User's first name. Name cased. 19 User's attempts to chat. 20 User's total number of logons/calls. 21 User's available minute-credits/extra download time. 22 User's hack attempts on name since last call. 23 User's total public messages posted. 24 User's total private messages posted. 25 User's total feedback to sysop messages posted. 26 User's total NetMail messages posted. 27 User's total NetMail messages received. 28 User's download minutes used today. 29 User's total number of files downloaded. 30 User's total number of bytes downloaded. 31 User's total number of minutes spent downloading. 32 User's total number of failed/bad download attempts. 33 User's total number of files uploaded. 34 User's total number of bytes uploaded. 35 User's total number of minutes spent uploading. 36 User's total number of failed/bad upload attempts. 37 User's total number of doors accessed. 38 User's Sysop-Note field. 39 User's User-Note field. 40 User's total messages ever posted. 41 User's total minutes allowed downloading per day. 42 User's total minutes allowed downloading left today. 43 User's elapsed time of the current logon/call. 44 User's age in years (goes by birth date field). 45 User's current connection baud rate/connection type. 97 BBS's phone number. 98 Sysop's full name. Name cased. 99 Sysop's first name. Name cased. 101 Current message area's title. 102 Current message area's message-op. 103 Current message area's minimum post SL value. 104 Current message area's minimum read SL value. 105 Current message area's minimum scan SL value. 106 Current message area's message-op's first name. 201 Current file area's title. 202 Current file area's file-op. 203 Current file area's minimum upload SL value. 204 Current file area's minimum download SL value. 205 Current file area's minimum scan SL value. 206 Current file area's file-op's first name. │ 1001 to 1051 User counts for each of the 50 states. │ │ 1100 to 1149 Top users ranked by DL bytes. Name cased. │ 1150 to 1199 DL byte numbers for them. │ │ 1200 to 1249 Top users ranked by files DL'd. Name cased. │ 1250 to 1299 Files downloaded numbers for them. │ │ 1300 to 1349 Top users ranked by UL bytes. Name cased. │ 1350 to 1399 UL byte numbers for them. │ │ 1400 to 1449 Top users ranked by files UL'd. Name cased. │ 1450 to 1499 Files uploaded numbers for them. │ │ 1500 to 1549 Top users ranked by logons. Name cased. │ 1550 to 1599 Logon numbers for them. │ │ 1600 to 1649 Top users ranked by msgs posted. Name cased. │ 1650 to 1699 Messages posted numbers for them. │ │ 1700 to 1749 Worst users ranked by DL bytes. Name cased. │ 1750 to 1799 DL byte numbers for them. │ │ 1800 to 1849 Worst users ranked by files DL'd. Name cased. │ 1850 to 1899 Files downloaded numbers for them. │ │ 1900 to 1949 Worst users ranked by UL bytes. Name cased. │ 1950 to 1999 UL byte numbers for them. │ │ 2000 to 2049 Worst users ranked by files UL'd. Name cased. │ 2050 to 2099 Files uploaded numbers for them. │ │ 2100 to 2149 Worst users ranked by logons. Name cased. │ 2150 to 2199 Logon numbers for them. │ │ 2200 to 2249 Worst users ranked by msgs posted. Name cased. │ 2250 to 2299 Messages posted numbers for them. │ │ For the top/worst users above, the number of users actually │ stored depends on what you set in Alter Settings. You may │ set it for more than 50, but you can only access up to 50 │ names this way. Numbers are displayed with commas. You should not use the "«" in any ANSI's before you get the callers name (all ANSI's before your "LogN" command). This character is used to tell the other computer when to receive net mail--it may trigger a premature net mail transfer before your BBS had planned. That is, if another BBS calls your BBS looking for net mail, it is looking for this character--since the BBS sends out this character to tell the calling computer to begin a net mail receive. If it appears in your ANSI's, it causes trouble. Once a user logs in, then you can use the character in any of your ANSI's. Auto-detect of Zmodem or BiModem is done at all menu ANSI's. For menu ANSI's, the who's-on status line is displayed on the next line following the ANSI--so it is not recommended you have menu ANSI's that exceed 23 or so lines. Menu ANSI's make an attempt to "hide" the cursor by putting the cursor somewhere on the screen where it will not be seen. See SHORT 442 for the command to use for this. Your ANSI's may require a different position or color, etc. It is a trick, and requires placing on a cursor position whose foreground and background matches that of the cursor. Hard to do at the console since the cursor is turned OFF. │ If the file name has a "???" it will be expanded to the node │ number. Any other wildcard, using "?" or "*" will cause one │ file of those found to be randomly displayed. ANSI Codes ANSI codes are marked by a distinctive "" as the first two letters. The "" is an ASCII 27, and the easiest way to create it in a text editor it to just copy it from another line. Code Meaning ──────────────── ─────────────────────────────────────────── r;cH Move the cursor to row r and column c. r;cf Starting from 1 (1,1 = upper-left corner). rH If c is excluded, then it goes to row r, rf column 1. xA Move cursor up x lines, or move cursor up A one line. xB Move cursor down x lines, or move cursor B down one line. xC Move cursor right x columns, or move cursor C right one column. xD Move cursor left x columns, or move cursor D left one column. s Save cursor position. Only one is saved, so you can call this repeatedly and you will still only get the last cursor position you had. u This puts you at the location your last "s" was when you did it. n Reports current cursor position. Report is of the form: "r;cR" Erase entire display and move cursor to 1,1. If a background color (besides black) is in use then the whole screen will become that color. To avoid this, use: "" Clear from the current position to the end of the line. If a background color (normally black) is specified, this will make that area that color. v;w;x;y;zm Where v, w, x, y, z are any of the w;x;y;zm following: x;y;zm 0 Normal (dull white on black) text. y;zm Turns off blinking and backgrounds. zm 1 Bright on. 5 Blink on. 3x Foreground color (see x below) 4x Background color (see x below) Colors (x): 0 = Black 1 = Red 2 = Green 3 = Yellow 4 = Blue 5 = Magenta 6 = Cyan 7 = White ABCD above, the directional move codes, will not go beyond the screen's borders. They also do not modify the "other parameter" (be it row or column). "xC" is particularly useful for efficiency. It moves the cursor farther down the line x characters, so, if you wish to move 5 or more spaces, or wish to "skip" 5 or more spaces (such as when you have background colors on) then use this rather than the spaces themselves, since it is less characters to transmit. The longest entry possible is something like: "". Which resets everything (0), turns bright on (1), turns blink on (5), turns red on (31) and turns black background on (40). What does this give us: bright red blinking text on a black background. Standard conventions: 0 first, 1 second, 5 third, foreground fourth, and background fifth. Most commands will usually only have two parameters: "x;ym", where x is 0 or 1 and y is a foreground color. Use 0 to produce normal (dark) text and 1 to produce highlighted (bright) text. If the colors do not change, you can just use "" to turn bright text on. However, the reverse is not true ("") since 0 alone resets the colors to white on black. Example: "Testing" Will produce a bright green "T" and a dark blue "esting". Use of backgrounds is more tricky and requires practice and patience. The key thing to remember: a "0" resets everything. So to "undo" a background color, use a sequence that starts with "" (ie. ""). LINES.TXT This is a standard text file that you may edit using any text editor. There are only five things to remember about the LINES.TXT format: The first four numbers represent a line number. The remaining text is the text to send/display out. The whole line cannot exceed 126 characters in length. Color is done using ANSI codes. Multiple lines can be used. The first four digits of every line (except those designated with a "'" to mark them as a comment, or "\\\\" to mark them as a continuation) is a "line number"--not THE line number which it occupies within LINES.TXT, but an assigned number. Starting with position 5, the rest of the line (not counting the CR/LF at the end of each line) is for the text that makes up that line. There are two types of text: starting text, and continuing text. See the SendTT codes about the various "" options. The one to pay attention to: "". This tells the software that the next line should be wrapped to the end of this one--you should then put "\\\\" as the first four characters of the next line. Here are a few useful locations: 0001 The logo line. 0002 BBS name (for doors). 0158 Shuttle logon password (if using it). 0625 Modem answer string (ATA). 0626 Modem initialization string (ATZ). 0627 Modem hang up string (ATH0). 0628 Modem take phone off-hook string (ATH1). 0626ATZ is of particular importance. ATZ is the initialization string your communications program sends to the modem upon startup. ATZ is for the HST- -and possibly others--but certainly not for run-of- mill 2400 baud modems. Consult the manual that came with your modem to decide on what to use for its initialization. The rest of the lines are "just text". When you see something displayed that you want to change--perhaps a different wording--then search for it in this file and replace it with what you want. When JDR_BBS is run, it generates an image file and an index file of your LINES.TXT--and it does not update the file unless it senses that you have made changes to LINES.TXT. Because LINES.TXT contains nearly all the text the program uses, it is accessed a lot. So it should always be the first file you think of when thinking about using a RAM disk. When using multi-nodes, remember to define files that use the RAM disk with different names (such as LINES???.$$$ for the image file). See also: SENDTT, ANSI'S SHORT.TXT The SHORT.TXT file is structured very much like the LINES.TXT files. Each line cannot exceed 126 characters, and the first four characters are a line number. Unlike LINES.TXT, however, you cannot wrap text to another line. The entire SHORT.TXT file is loaded into memory (into the string space). The lines in this file mainly represent "system" stuff. Or "language independent" stuff--text and stuff that does not require translation to a different language. Here are a few useful locations: 0001 to 0039 Words to censor out of descriptions. 0040 to 0049 Words to censor out of messages. 0050 to 0064 Words to upper case in messages. 0070 Entering messages: far background color. 0077 Entering messages: message body color. 0252 Words which cause chat rejection. 0350 to 0359 Words which cause search file rejection. 0820 Local call dialing prefix (an AT is added). 0839 Long distance dialing prefix (an AT is added). 0851 to 0860 <ctrl>Fx defined key menu commands. 0070, the far background color is 1;34 (a medium blue) now. But most any color works good (including 1;30, a grey). I do recommend you try the different colors (0;30 to 1:37) and decide on one to your liking--different colors produce very different looks for the message-entering system. BLOCKS.TXT Blocks are lines of text that have the same first two numbers. Blocks contain various things: DataBaser definitions, text blocks, "SelM" and "SelF" areas-to-use, and program blocks. Usually anything over 5 lines is put into one of these blocks. In .09 I will be breaking this file up into about 5 smaller files; each containing the same type of blocks. Here is a couple useful locations: 07 AI's "go fish" message text. 37 "SelM" Net Mail message base selector I have set up. 49 Node address help--you should replace with your node and BBS information. 63 "John's Address" option--change to your own. 69 .QWK mail "your BBS is" stuff. 78 Text for the terminal program. For text blocks when using the "dBLK" command: a "" at the end of the line will stop the output of a CR/LF when that line is displayed (allowing for multiple lines to be merged) and the final line does not get a CR/LF after it (allowing the final line to be a question). SECURITY The software will allow you to work with security levels in LEVELS the range of -32,767 to +32,767. Using negative values, however, might not be recognized in some routines. There are no "locked in" security level values. Users may have any security level value. The software will either use their SL directly ("if SL < x then ...") or indirectly ("if SL is > x and SL is < y then ..."). This allows you to use the security level system as a "reward" and "punishment" system if you want. I just use a simple six level scale (5, 10, 20, 90, 95, 100) myself, but you can do what you want. When entering a range of SL's (some options allow this), you must use " to " to separate the numbers (eg. "90 to 100"). Important: When entering the security level data in the Security Levels database, you must enter the values in increasing order (for example, 5, 50, 500--not 5, 20, 10). So that when done, your first entry contains the lowest value, and your last contains the highest. The highest is assumed to be the sysop level. The lowest is assumed to be the new user level. After changing your SL's in the SL's database, you should run "Update Stats", or you will just get nonsense when doing a "Stats Display". Do not mess around with the security levels for message area 001, Private Mail. All users need to be able to access this area, so your SL's for accessing this area should always be equal to, or lower, than your lowest defined SL. SL's (used in commands, etc.) do not have to be an SL value in your SL database. │Ghosting Some BBS programs use "user flags" as an enhancement to their │ SL system. A user would have to have both the SL and the │ flag(s) to do a command. │ │ I have a system just as powerful. It is called "SL │ ghosting". │ │ It is simple: you have two security levels; one that users │ see, and one that the program uses. │ │ When at the SL database, the real security level is referred │ to as the "SL value" and the security level the user see's is │ referred to as the "show SL". │ │ This allows you to give a user of, say, real SL 4 30 minutes │ per day, and one of real SL 5 60 minutes per day, while │ having both of them think they are level 5 because both SL's │ have a "show SL" of "5". │ │ But besides simple user limits, the real use for this is with │ menu commands. Providing a way to separate your users │ internally without them knowing about it. EXAMPLE ┌───────────────────────────────────────────────────────────┐ │Your BBS has the following time guidelines: │ │ │ │ Normal user: 60 minute limit per week │ │ Donated $1 : 70 minute limit per week │ │ Donated $10: 100 minute limit per week │ │ │ │Then in your SL database: │ │ │ │ Real SL Show SL Free Minutes │ │ 10 10 60 │ │ 11 10 70 │ │ 12 10 100 │ │ │ │Thus you have three different limits, three different SL's,│ │but the users never know it--they all think they are level │ │10. │ └───────────────────────────────────────────────────────────┘ SYSOPS For message bases, file areas, and doors. The sysop of that area is the one true sysop in that area--the real sysop being just another user. For most other things, when I say "sysop only", what I really mean is anyone with a sysop-level security level. Pay attention to some of the commands, they offer different options and displays depending on whether the user is a sysop or not. FILE AREAS The following can be set in Configuration in the File Areas database. Path This contains the path to which this file area refers. Title Refers to what the users see when as the title when they list the contents of that directory. Download SL Only when a user has at least that security value, will they be able to download files from that area. Upload SL Only when a user has at least that security value, will they be able to upload files to that area. Access SL Only when a user has at least that security value, will they be able to list the contents of that area. Attributes │ The area may have eight attributes: 12345678. "1" is DATE. Which means that you wish the file's date to be shown when listing the contents of the area. The space used by the date comes at the expense of the description. Since file dates are often unreliable, I prefer the extra description length for the UPLOADS area, but I do use the date in the other areas. "2" is LOG. Which means that you wish uploads and downloads to/from this area to show up in the callers log file in such a way that all users can see it. "3" is L&D. Which means that you wish the L&D/Point values to be shown when listing the contents of the area. Setting this OFF overrides the user's toggle to view the L&D/Point values. "4" is UPLD. Which means that users may upload to this area. When not included, any uploads attempted to this area go to area number 001 (if possible). "5" is ORDER. Normally files are listed in alphabetical order (A to Z). When this is ON, files will be listed in order from newest to oldest. Normally when you have DATE ON, the current date of the file on your disk is shown. But when ORDER is ON, then it shows the date the file was uploaded instead. │ "6" is TRANS. Which means that files in this area are said │ to be "transient". This is for such as floppy or CD-ROM │ drives--where you swap in and out disks of files. When │ this is ON, auto-deletion of file entries not found is │ turned off. Example: You have two floppies, each with two │ files. With this OFF, each time you exchanged floppies the │ system would automatically delete the file entries of the │ files on the out floppy. With this ON, you can swap the │ floppies without having to redo the descriptions each time │ you swap in a new disk (although you do have to do them the │ first time, like any new file). See the "MLsC" command. │ "7" is NOEXT. Which means that when this is ON, no file │ name extensions (.ZIP/.ARJ/etc.) will be shown on │ description lines when listing a file areas contents. This │ saves 4 characters per line, which can slightly speed up │ output. │ "8" is COUNT. Which will put the total number of files in │ the area into the top header line when listing the contents │ of the area. Start Time End Time A user may download, list, or upload files to this area only during the defined hours. Note that, starting an upload or download inside the valid time, that then extends outside the allowed time (eg. downloading a massive file) will be allowed. Circular buffer size. If this field contains anything other than zero, than the file area is said to have a "circular buffer". Whenever the number of files in that area reaches this value, the oldest file will be deleted. Example: if you set it to 50: if there are 50 files in it, and someone uploads 3 files to this area, then the oldest 3 files will be deleted. So there will be 50 files again. If there were 45 files, then it would have 48 files--since it did not reach 50, there was no need to delete files. A zero value in this field means there are no limits on the number of files that can be active in this area (although you should make sure the number does not exceed your "max files in dir" setting--see SETTINGS). Oldest file being the one in the area/on the BBS the longest--not by current file date. File-Op This is a name field, and contains the name of the "overseer" of that file area. You, the sysop can do many file functions, including delete, modifying the descriptions, etc. Including a name here will allow that user to ALSO do these functions (only one name allowed). Only those with "sysop" security levels, or the name in this file-op field will be able to "work on" files in this file area. Useful for delegating the maintenance of a file area to a user. High-File-Pointer This is a primarily internal field, its a storage location for the highest HiFilePtr the area has seen. If you choose to use the internal menu for switching file areas (versus using an ANSI) then those areas with new files will be highlighted for the user. When you start up the BBS, it checks to see what files are where, etc. If you accidentally renamed your downloads directory, and did not update this in the File Areas database (or vice-versa), then it is possible you could find that startup procedure declared all your files deleted (and recorded so in the log). Do not panic! Just get the directory names correct, and restart. You will find that the software, having realized its mistake, undeletes all your file records. No files are ever actually deleted, it is just the software doing some accounting for you. Upload-stopping works as follows: If the current area does not have UPLD, or the SL for the area is too high for the user, then we change to area 001. Then the same checks are made, if the user does not pass them all, then they are not allowed to upload. Menus The software will provide you flexibility to access your file areas with whatever method you want. These include: internally (quick) generated menu, ANSI menu, and continuous systems. Internally (quick) generated menus: These involve making use of the "_Bxx" and "_all" some commands have. "SelF _all", for example, will give you a menu of all file areas you can access. "SelF _Bxx" will retrieve BLOCKS.TXT block #xx (of the form: xxxyyyzzz...) and produce a menu of those file areas to which you have access. After the menu, the "SelF" command merely switches to that file area. Other commands are "LstF", "PagF", and "Upld". All work similarly with the "_all" and "_Bxx" by first bringing up a menu and then Listing (continuous method), Listing (paging method), and uploading to, respectively. ANSI menus: This involves putting individual commands into an ANSI. Once again, the commands are: "SelF", "LstF", "PagF", and "Upld". However, instead of using the "_Bxx" or "_all" extensions. You use these commands with no extensions (except "SelF") or with the "_xxx" extension (where "xxx" is a file area, eg. 001). Additional commands of use are: "PrvF" and "NxtF" Continuous systems: These are extended listing systems. They include "PagQ", "PagA", and "P&Sx". "PagQ" will ask you what you want to do. "PagA" will cycle though all the file areas accessible using the paged method. "P&Sx" is the Point & Shoot system. You can create a continuous system for the continuous method of listing files as such: LstF _001 LstF _002 LstF _003 LstF _004 This new command would cycle through your 4 file areas. A common factor to all the systems is the batch download buffer. It's accessed via commands in the paged method. It's part of the P&S system. And you can use "CntB" and "AddB" for ANSI menu options. By having this wide variety of commands, you may put file areas any where you want. You could, for instance, shove them into a bunch, or break them up by topic--each having its own message area, menu, etc. From "P&Sx" if you hit "." you get a "LstF" of the current area and it will loop through the rest of the areas using "LstF", or until "." is hit again (when it returns to the P&S screen). While the P&S screen won't show the users areas they don't have access to, using "." to get into the "LstF" version of "P&Sx" will show those areas, but say "SL to low to access". From "LstF" or "PagF" (but not "PagQ" or "PagA") "." will put you into the P&S system. The P&S system will not show areas the user does not have access to. The commands can be thought of as differing ways of doing the same thing. For instance, "PagQ" is one menu command, but requires two key strokes to do something. You could do the same with 4 menu commands ("PagA", "PagN", "PagF _all", and "PagS") requiring only one keystroke. Same thing, different philosophies for different sysops. Similarly, a function like "LstF _all" is one command, but you could just as well create a full menu with a bunch of individual "LstF _xxx" commands (particularly so if you want your own menu's look and feel). See also: MENU COMMANDS: File Diagrammed "LstF _001 LstF _002 LstF _nnn DReq" menu command: File Examples ┌────────────────┐ ┌────────┴───────┐REQUESTS│ ┌────────┴───────┐ AREA n │ request│ ┌────────┴───────┐EA 002 │ze desc │ request│ │ FILE AREA 001 │ze desc │ze desc │ request│ │ file size desc │ze desc │ze desc ├────────┘4 │ file size desc │ze desc ├────────┘3 │ file size desc ├────────┘2 └────────────────┘1 The user has to hit [Enter] to move to the next area. There is no way to jump out of the areas (hitting [Enter] fast does it). Recommended for less than 5 areas, or for when you have areas you want to force the user to look at. All areas are "attempted at", but the contents of areas to which users do not have access are not shown. Listing method is continuous. "LstF _all" menu command: ┌────────────────┐ ┌────────┴───────┐AREA: │ ┌────────┴───────┐EA 002 │a 001 │ │ SELECT AREA: │ze desc │a 002 │ │ A) area 001 │ze desc │a n │ │ B) *area 002 │ze desc ├────────┘1 │ C) area n ├────────┘2 └────────────────┘1 A menu is presented containing all the file areas. When they select an area, they are given the contents listing of that area (continuous method), and then return back to the menu. Only areas to which the user has access are shown in the selection menu. "P&Sx" menu command: ┌────────────────┐ ┌────────┴───────┐EA 001 │ ┌────────┴───────┐ AREA n │le file │ ┌────────┴───────┐EA 002 │le file │le file │ │ FILE AREA 001 │le file │le file │le file │ │ file file file │le file │le file ├────────┘1 │ file file file │le file ├────────┘3 │ file file file ├────────┘2 └────────────────┘1 The user has a wide selection of commands while at the P&S display. You can move both forward and backward through the file areas. Only those file areas to which they have access do they see. "SelF _Bxx" menu command: ┌────────────────┐ │ SELECT AREA: │ │ A) area 001 │ │ B) *area 005 │ │ C) area x │ └────────────────┘1 A menu is presented containing certain file areas (defined in a BLOCKS.TXT block). When they select an area, they are exited from the areas menu. Only areas to which the user has access are shown in the selection menu. "PagA" menu command: ┌────────────────┐ ┌────────┴───────┐ AREA n │ ┌────────┴───────┐EA 001 │ze desc │ │ FILE AREA 001 │ze desc │ze desc │ │ file size desc │ze desc │ │ │ file size desc │ ├────────┘3 │ Option: ├────────┘2 └────────────────┘1 Each file area is gone through. At every 18 file names or at the end of a file area, a prompt is displayed. At this prompt the user the user has a wide selection of commands including commands to move to any area number. The listing format is the paged method. This command is exactly the same as "PagQ" with the user selecting "A" for all areas. "PagF _all" menu command: ┌────────────────┐ ┌────────┴───────┐AREA: │ ┌────────┴───────┐EA 002 │a 001 │ │ SELECT AREA: │ze desc │a 002 │ │ A) area 001 │ze desc │a n │ │ B) *area 002 │ze desc ├────────┘1 │ C) area n ├────────┘2 └────────────────┘1 A menu is presented containing all the file areas. When they select an area, they are given the contents listing of that area (paged method), and then return back to the menu. Only areas to which the user has access are shown in the selection menu. Remember that at the end of menu commands, you can put a "DReq" to force the showing of the requests list. The difference between a "PagA" and a "PagF _all" are in scope. "PagF _all" is equivalent to a bunch of individual "PagF _xxx"'s--so you cannot move between areas like you can with "PagA" or "PagQ". Files In Area When you place files in a download area--either copying or downloading from another BBS--then these files are said to be "outside the software's domain". That is, the software does not yet know about it. So, some functions, that require an active file's filename will not yet "see" the file. However, as soon as they are "seen"--when you or a user lists the files in a download area--then they are "discovered" and given an entry, making them active. When the software discovers files, the files are assumed to be complete, and just given a blank description (shows up as "?"). │Misc. The file system is optimized for lots of files in lots of │ directories. Unless you have a fast computer, lots of files │ in a few directories will be awkward. The reason for this: │ because when listing each directory, the contents of that │ directory are read into memory (from DOS) and then sorted. │ │ Large collections of files in an area will also use up more │ of your RAM, since appropriately sized arrays need to be │ maintained. │ │ What the limits are, are pretty much up to what you perceive │ as too slow, or the conditions under which the BBS is │ running. │ │ Hundreds of files per directory are no problem on any system. │ Thousands become a problem on slow computers. │ │ To get around the slowness, use the "show by newest" toggle │ when you want super-large file directories. You should also │ then make the "maximum number of files per dir" setting │ something more reasonable (but at least 100)--since the │ software will not have to sort it, so this will change space. │ │ If you REALLY want to screw up the software, have lots (like │ 20) file areas with lots (like 2000+) files per. And with │ some areas to be listed alphabetically and others by date- │ uploaded. In this case, you really should have a 386. │ Because sorting 2000+ files will probably show up as a sharp │ delay before each file areas listing otherwise. │ │ Example: Exec-PC has about 20 areas, by computer type, with │ file counts ranging from 45,000 to a couple of hundred. He │ uses a list-by-date-uploaded method. If you have a similar │ system, that is what I would recommend. Using an │ alphabetized list with thousands of files is wasteful. │ │ But Exec-PC is a large pay-per BBS. Most BBS's specialize in │ one type of computer. These have lots of areas, by software │ topic, with not so many files. Example: 30 file areas with 1 │ to 300 files per. For this, either alphabetically or by │ newest would do just fine. It is a sysops preference which-- │ I myself like to see the lists alphabetized and let the users │ use "new stuff" or "PagQ with New" to list just the new │ files. MESSAGE AREAS There are 8 message area attributes: 12345679 "1" is ANONymous. Which means that the FROM: field will contain "Anonymous" and nobody (but the sender) knows who left the message. "2" is PUBlic/PRIvate. Public means the messages posted there are visible by all. Private means the messages are only visible to the sender, receiver, or message-op. When using the various message reading menu commands, pay attention to which read private mail, and which read public mail. They do not read each other's type. "3" is NET. Which means that the area should be inspected when receiving or sending Net Mail packets. It is also necessary if you wish to enter a node address when entering mail, and seeing the node addresses when reading mail. If an area does not have NET, then no Net Mail will be put there, and no messages will be sent out from there. Also, NET tells the software to add special "^A" "kludge" lines to the message. You can really have only two NET-only areas: private NetMail, and public NetMail. With private NetMail, any private Net Mail that does not have a matching EchoMail message area will be put here. Similarly for public NetMail. If you have only one NetMail area, then both private and public NetMail goes there. No NET areas? Then NetMail will be put into the private mail area. "4" is LOCK. Which means that the user must be unlocked to to use the commands Read Mail, Leave Mail, and Scan Mail when using this message area. The message-op field is extremely important if you wish to have locked/limited access to the message base. As ONLY the message-op can lock/unlock users to that message base--even the sysop cannot if they are not the message-op. The locking system is also known as a conferencing system--in which you allow or stop users from accessing the message area without some sort of prior processing. The user has toggling to turn ON and OFF message areas, the message-op has LOCKing to turn users ON and OFF in message areas. "5" is DEL. Which means that only the message-op can delete any messages in the area. "6" is ALL. Which means that all messages are given "ALL" as their "TO:" field. This includes replies. Nobody is allowed to enter a name in the "TO:" field. "7" is ^A-ON. Which means that NetMail "kludge" lines are shown (these lines begin with an ASCII 1--a little happy face). This also toggles the showing of EchoMail lines: ---, * ORIGIN:, SEEN-BY, and AREA:. "9" is ECHO. Which means the area is an EchoMail area. NET must also be set to on for any ECHO area. Basically, an ECHO flag tells the software to add an AREA: line to each message. You may mix-and-match the above attributes. Menus The message area commands are quite similar to the file area commands. For instance, "SelM" to select a message area is just like its "SelF" brother. Most of the other commands, for reading and writing messages, are less generalized and usually only offer the non-parameter form (uses the current area) and the "_xxx" parameter form (switch to area "xxx" first and then do the command). See also: MENU COMMANDS: Message PEER REVIEW Peer Review is a restriction system--to restrict users. To turn it ON for all new users, use "User Maintenance" to set bit "0" to ON for #NEWUSER's attributes (you will need to do this again if you re-initialize #NEWUSER). To turn it ON for a single user, set bit "0" to ON in that user's record with "User Maintenance". When reading mail, when you, the sysop, hit "?", the message is sent to a message file, and the user is tagged as undergoing Peer Review. Should you hit "?" for another message from a user undergoing Peer Review, then this message is also added to the message file. When users of a defined security level value range log on, they may vote on these message files. To lessen the hassle to those users in the range, they are only given one to do per logon. Those already voted on are skipped, and users may not change their vote. If the user hang's up while in the voting mode, their vote is cast as "Don't Care" for that review. At each logon, a user undergoing Peer Review will be given the tally so far. When the number of positive or negative votes exceeds a value you specify, then that user is said to have passed or failed Peer Review. They will be given whatever SL value you specified. A message will also be sent to them telling them they passed or failed. When a user passes or fails, that fact is recorded in the log for all to see--so those who care about how the voting went can find out. The complete review file is moved into DEL_MSGS.TXT. This system can be useful for limiting beginner users. It is also useful for accounting. If you double-bytes-off a user, and they go below their ability to download, the process discourages "jumping to another account" and encourages one to repair their account rather than abandon it. When a user is undergoing Peer Review: during the login process, if they do not have any mail waiting, they are offered a chance to see what the voters see. See also: SETTINGS, Ninf WAITING FOR The Waiting-for-caller screen contains 5 "objects" of CALLER SCREEN information: drive/mem stats, help/sysop info, modem status, BBS status, and callers log. The drive stats section, upper left corner of the screen, shows the available memory on drives you have deemed important enough to show this (in "Change Settings"). You can hit <F5> to show some memory information instead. The memory info is: amount of RAM the BBS "see's", amount of internal string space and the amount of internal stack space the software has. │ The help section, upper right corner of the screen, shows the │ various keys you may select at various times. You may page │ these screens with the "+" and "-" keys. Hitting <F7> will │ lock down (until a full exit is done) two stats windows: one │ shows messages and files new to the sysop, the other shows │ when the next event is scheduled for and when was the last │ time the software checked to do events. The callers log, bottom half of the screen, shows the last few callers log entries. You may scroll this using the up and down arrow keys. The lines in the middle of the screen gives the time the waiting-for-caller was started (time last user logged out, or last event finished). It also tells how much time is left before it resets the modem, and shows you a counter to that time. The 6 "buttons" are "CTS", "DSR", "DCD", "Trap", "Chat", and chat availability. "Trap" and "Chat" are ON (pushed in) when you have trap-all or chat trapping ON. "CTS", and perhaps "DSR", are usually ON or OFF depending on your modem. Usually when a call is received the "DSR" will go ON and then the "DCD" will go ON. The final button is the chat availability toggle. This is turned ON/OFF with F3 when at the waiting-for-caller screen or when a user is on-line (a music symbol appears in the status line when ON). When this toggle is OFF, the user will not be able to try to chat with you. The symbols, "══" for ON, and "═─" for OFF, breakdown as so: the left face is that of the caller, the right face is that of the sysop, there is a line of communication between the ears and mouths, when you have your end turned OFF then you cannot hear what the user is saying, but still can say something to the user anytime you want (that is, the user cannot call you via chat, but you can still jump into chat if you want to talk to him). When the phone rings, a "[RING]" appears in the middle of the screen. After a carrier is detected, the string received by the modem is displayed as it is received. A "│" marks a CR/LF. After the phone rings, the software will start its "logo" timeout countdown (I have it for one minute now). If no carrier is found at that time, the phone is hung up. When a carrier is found, the clock will stop ticking. The "logo" time-out is reset, and starts (internally) again. The string received by the modem is displayed as it is received. Usually it will take a couple of seconds until connection speed is determined. However, it could last the full "logo" time-out time if the connection was one you had not specified in your CONNECT strings database (for instance, this occurs with 1200 baud callers when you do not want them). This is because, for baud rates you do not want, the system merely waits for that caller to hang up, or for them to time-out. You will not be able to use any keys from the console during this period. Entries are recorded for "bad connects". They are of the form: "Non user called at <time>. Connect: |...|". The "|...|" is the crucial information. It will tell you the exact string the software received from your modem. A bad connection may contain just garbage, a 1200 connection would look like "| 1200<garbage>|" usually. If you forgot any CONNECT strings, this will tell you the information you need. See also: SETTINGS, CONSOLE KEYS SENDTT When ever the software uses its own text--that is, text users do not enter--it searches for certain control information within the text: ! will insert the sysop's first name. ? will insert the user's first name. > to output a CR/LF. + to turn pause-allowed mode on ([Space] pauses text). * for a 1 second pause. -xx to produce "┌───┐" of length xx (must be two numbers). || (eg. |12Q~|) this sets up a list of stop-and-exit keys for that line of text that the user can hit. For [Enter] (an ASCII 13), use a "~" character. Not really something useful to you, as there must be program coding to make use of any keys hit. @@ (eg. @E:\4THJULY.ANS@) will output the file between the two @'s. This is useful for really long text or ANSI strings. Can be used to add long special effects to menu responses. No key checking--such as for cancellation of output--is done during the display of the file. You can use wildcard's to select a random file from among whichever number match. τ Will display your header line (LINES.TXT line 001). _xx to produce "▄▄▄▄▄" of length xx (must be two numbers) two lines below the current line. These are codes for internal use only (either in BLOCKS.TXT or LINES.TXT). These could not, for example, be put into an ANSI file (such as menus) and expected to expand out. They are filtered for (stripped out) incoming text, imported, uploaded, and net messages. The LINES.TXT file has another special code: which is not a formatting code but a "there is another line" code. DATABASER The DataBaser system is a sysop-designed data base system. All DataBaser databases rely on BLOCKS.TXT to define and "DBEd" or "DBVw" menu commands to implement--making them free of the hardwired code. However, I do use the DataBaser system for some of my own internal databases (Message Bases, Sysops, Doors, etc.) which may have some specific coding. Either way, for my internal databases, you should not change the entries in BLOCKS.TXT. BLOCKS.TXT Each DataBaser definition has a format along the following DataBaser lines: Structure Line 1: Descriptive text about the database. Appears ... when the menu command is called. Line n: <end> Line n+1: database's file name. Line n+2: database's definition specs. Line n+3: Question line to use when modifying. Line n+4: The object name of the record type (subject of the database). Line n+5: Heading output text. Appears at top of listing. ... Line n: <end> Line n+1: Body output specs. ... Line n: <end> Line n+1 to end: text describing each field. Example: 50Fuzzy Bear's data base of warez. 50 50<end> 50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT 50S12S40U 50record number : 50warez 50 -------- Fuzzy'z Warez Data Baze --------> 50 Rec ==File Name== ===============Description============== ========User=======>> 50<end> 50<04 <13 <40 <19~ 50<end> 50File name 50Description 50User name The "50" means this is block number 50 in BLOCKS.TXT (and it comes only after block 49 and before block 51). 50Fuzzy Bear's data base of warez. 50 50<end> Is our description text. It can be any number of lines, but must be at least two lines, and the last line must contain only "<end>". It may contain SendTT formatting codes. A CR/LF is assumed after each line. When this database is called, it will clear the screen, print the BBS heading, print "Fuzzy Bear's data base of warez." in dark green letters, skip a line, then ask the "List, Add, Modify, Delete, Insert, or [Enter] to quit" question. 50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT This is the file name in which we store our database. You can specify any pathname you want. 50S12S40U This is the database's definition specs. The following are currently allowed: A for an attribute field. Inputs and displays attributes using "1234567890ABCDEF". F for file areas. Input is for a 3 digit number, but output contains the number and the title of the area. I for an integer number (-32767 to 32767). L for a long number (-2,100,000,000 to 2,100,000,000). M for message areas. Input is for a 3 digit number, but output contains the number and the title of the area. N for a node address (xxxxx:xxxxx/xxxxx). P for a U.S. phone number. Sxx for a string of length xx. xx must be two digits. Example: for a string of length 4, use S04. S02 is special: it is always replaced with a CR/LF. S64 is special: it is considered to be a pathname, and will be created if it does not exist and the entry you make ends in a "\". T for a time field (HH:MM:SS). U for a users name. The auto-name-detect is in effect so only active BBS users names are allowed. Use S30 for non-auto-name-detect name fields. W for the seven days of the week (MTWRFSN). "R" for thursday and "N" for sunday. anything else will cause trouble. Our example describes a database of 3 fields: a size 12 string field, a size 40 string field, and a user name field. For a total record length of 82 characters (user names are limited to 30 characters). For those who need to know: A, F, I, M, T, and W are stored in 2 byte integer form, L and P are 4 byte long form, U is a 30 byte string, N is a 6 byte string, and Sxx is a string of length xx. 50record number : This is the "modify which entry" question fragment. For adding, deleting, inserting, etc. it asks "Modify with ..." and appends the above. 50warez This describes what we are working with. It is used when adding. In this example, after selecting Add, it will display "Adding a new warez." 50 -------- Fuzzy'z Warez Data Baze --------> 50 Rec ==File Name== ===============Description============== ========User=======>> 50<end> Is our header text. It can be any number of lines, but must be at least two lines, and the last line must contain only "<end>". It may contain SendTT formatting codes. No CR/LF's are added unless you put them in with ">". 50<04 <13 <40 <19~ 50<end> This is our output display definition line. It contains two defining elements: "<xx" which is the length to use, and everything in between. For each definition in our definition specs, there should be a corresponding "<xx". You cannot not-do a field, but can not-show a field by using "<00". The first one is for the record number. Two numeric digits are required (for example, not "<9", but rather "<09"). The example tells the software to display a line of the database as so: Turn bright green on, display the record number in a area 4 characters wide, display a blank space, turn bright blue on, display the filename in a area 13 characters wide, display a space, display the description in an areas 40 characters wide, display a space, display the user's name in an area 19 characters wide. We could have used two spaces before <13 and used <12 instead, or no spaces before and <14 instead--since the field is only 12 characters in length, the first two will always be spaces. The <19 truncates our 30 length file name. Output lines cannot exceed 79 characters (the software chops off anything longer). A "~" will be replaced by a CR/LF. All lines before the <end> are merged together before handling is done--so instead of thinking of it as a bunch of separate lines, think of it as one line broken up. When displaying, the following formats are used: Time: fixed "00:00 xm" format. User name, String: left justified. Integer, Long, Phone number: right justified. Days of week: MTWRFSN with "off" days getting a space. Attributes: 1234567890ABCDEF with OFF bits getting a space. File/Message areas: "xxx title" with title left justified, use <xx to limit what you want to see. Node address: "xxxxx:xxxxx/xxxxx" format. 50File name 50Description 50User name These are the field names used when entering/modifying a record. Simple names, one for each definition spec. When entering a day of the week, or attributes, they can be in any order, MRF need not be entered as "M R F ", for example. Calling Via Calling up a database involves using a "DBEd" or "DBVw" menu Menus commands. Any user with access will be able to do all the functions (List, Add, Modify, Delete, Insert) with "DBEd". You can just list the contents of a database using the "DBVw" menu command. See also: DBEd, DBVw Modifying When modifying the data, just hit [Enter] at the start of the line to not change what is already there. Deleting When deleting message bases, the MESSAGES file (and the messages themselves) are not affected. If the deleted message base has any active messages, then these will "reappear" the next time you create a message base for that message base number, or they will be deleted when you next do a pack files. Remember to not think of the entries as individual entries, each entry holds a slot--and when you delete an entry, all entries after it are moved down a slot. Delete record 4, and record 5 is now record 4, record 6 is record 5, etc. I strongly recommend that you do not delete stuff--but rather modify the entries appropriately. This reduces confusion. For records whose placement does not matter, deleting is no problem, but for stuff like doors, where placement means what menu command to use, it is extremely important. More The above may at first seem confusing. But there are plenty of examples. You will be using a lot of the already defined databases. Use these to study how to really make what you want. When listing, all final lines are trimmed of trailing spaces. If this is something you do not want, put something like a "" after the spaces. If an output line was only to output one field (not zero fields, not more than one fields) and that field is blank, then the line will not be outputted. That is, if an entry uses the full line, and is blank, it will not be shown. This is useful for large fields (eg. S64, S72) since the extra lines these incur when listing makes reading more difficult. EXAMPLE ┌───────────────────────────────────────────────────────────┐ │ Let us create a "news items" database. In which users │ │ can add/delete/modify/list entries of news items they │ │ think other users would be interested in. │ │ │ │ Step 1 │ │ Find a location for our DataBaser definition block in │ │ BLOCKS.TXT. Usually just use the next one following │ │ the last block in the file, for example, we will use │ │ 43. │ │ │ │ Step 2 │ │ Create some informational text for whenever this │ │ database is used. │ │ │ │ 43Important news items you wish all to see. │ │ 43 │ │ 43<end> │ │ │ │ This displays "Important news..." in dark green │ │ coloring followed by a single blank line. │ │ │ │ Step 3 │ │ Assign a file name to store our data. │ │ │ │ 43C:\BBS\GLOBAL\SYSTEM\NEWS.DAT │ │ │ │ Step 4 │ │ Define the data structure to use. We want a more "free │ │ flowing" structure than normal. │ │ │ │ 43S72S72S72S72 │ │ │ │ Which is 4 lines of length 72 (4 string fields of │ │ length 72). We could add more (or less) of these, we │ │ could change their size, etc. But this provides a good │ │ balance between drive space and entry size (each entry │ │ will use 4 * 72 bytes of drive space). Also, it is a │ │ good size to fool the user into thinking they are not │ │ entering into a database--as it will look like a text │ │ file (when we are done). │ │ │ │ Step 5 │ │ Now we enter the text for the question when a user │ │ selects to modify a record. │ │ │ │ 43news item (1..n top down)? │ │ │ │ Step 6 │ │ Identifying the record. "What it is" we are adding, │ │ etc. This is meant to be a singular noun. │ │ │ │ 43news item │ │ │ │ Step 7 │ │ Create a heading. │ │ │ │ 4326 News items of │ │ 43 interest.>> │ │ 43<end> │ │ │ │ We output "News items of interest.<ret><ret>" in bright │ │ green for our heading. │ │ │ │ Step 8 │ │ Design the record display line. Here is where we take │ │ advantage of some of the DataBaser system's qualities. │ │ │ │ 43<00 <72~ <72~ <72~ <72~ │ │ 43<end> │ │ │ │ We use " <72~" to print out each of the record lines │ │ with 4 spaces in front and a CR/LF afterwards. If the │ │ line/field is blank, then DataBaser will not output it, │ │ because it does not output lines with only one field, │ │ and with that field blank. The "<00" says to not │ │ output the record number (actually, it says "output the │ │ record number into a field of size 0). The last "~" │ │ will result in an extra CR/LF between the outputted │ │ records. │ │ │ │ So, now when we list, it will list all entries, │ │ separated by a blank line. It will only list as many │ │ lines per entry as contain data. Example: an entry │ │ with 2 lines of text shows only 2 lines, etc. Not a │ │ steady 4 lines per output record, even though the │ │ record can work with up 4 lines--by stopping output of │ │ "blank" lines, the actual number of displayed lines │ │ will vary with the number of fields witch actually │ │ contain data. │ │ │ │ 43}7<02 <72~ <72~ <72~ <72~ │ │ 43<end> │ │ │ │ Could be used to display the item number as well. │ │ Above the items appear in the default dark white color, │ │ here we turn on dark blue for the number, and dark │ │ white back on for the text. │ │ │ │ Remember, this entry does not define how each line of a │ │ record is to be displayed, but rather how the whole │ │ record is to be displayed. │ │ │ │ 43<00|o| <72|o|~|o| <72|o|~|o| <72|o|~|o| <72|o| │ │ 43 <*-+-*> │ │ 43 |o| │ │ 43<end> │ │ │ │ This is another example. This displays each item in a │ │ "paper feeder" like format. With a short design as a │ │ separator. Remember that the lines are all linked │ │ together to form a single string. │ │ │ │ Step 9 │ │ Because we have defined four fields (S72 * 4) we must │ │ now give each a name (for when we add/modify the │ │ entry). │ │ │ │ 43Item │ │ 43Item │ │ 43Item │ │ 43Item │ │ │ │ When adding/modifying an entry, we will be adding to 4 │ │ fields with the same name. But because the whole │ │ record is considered a single news item, this is quite │ │ appropriate. │ │ │ │ Finally │ │ We have completed a new database. Now we just give it │ │ an entry on a menu's ANSI, and a matching entry in │ │ McEditor with the command "DBEd _B43". Review the menu │ │ system for help with this procedure. │ │ │ │ NOTE │ │ While this database was designed to let users add │ │ entries, you can utilize it as your primary news file │ │ as well. Either replace the "Dnws" with a "DBVw" or │ │ add a "DBVw" command before or after "Dnws". Then when │ │ users log on, they will get a listing of your news │ │ DataBaser contents. │ │ │ │ One drawback with this database--any user can modify │ │ any other user's news item. Well, it might actually be │ │ useful here, but it would be disastrous if this were, │ │ say, a Buy/Sell/Swap database. │ └───────────────────────────────────────────────────────────┘ DIRECTRY'S Directry's are collections of information stuck into one file. There are three files for each directry: DIRECTRY.Dxx, DIRECTRY.Txx, and DIRECTRY.Ixx. The software creates DIRECTRY.Ixx. DIRECTRY.Dxx contains the information. This file can have three formats: LINE files consist of: LINE HEADER/NOHEADER %%% text line 1 text line 2 text line 3 . . . text line n Use LINE formatted files for when the information uses only one line. Lines should not exceed 126 characters. BLOCK files consist of: BLOCK HEADER/NOHEADER %%% text line 1 . . . text line n %%% text line 1 etc. Use BLOCK formatted files for when the information uses multiple lines. Lines should not exceed 126 characters. LENGTH files consist of: LENGTH HEADER/NOHEADER %%% size text of size bytes %%% size etc. Use LENGTH formatted files for when the information is of text either not having CR/LF's or that with lines of more than 126 characters in length. There is no limit on the size of the text. The key information to remember: The first line contains the information type (LINE, BLOCK, or LENGTH). The second line contains whether the screen should be cleared and the logo (LINES.TXT line 001) displayed (HEADER/NOHEADER). The third line is our first "separator line" and consists of "%%%". From then on we alternate between information and "%%%" lines. DIRECTRY.Txx files are of the form: First line: Line of text that makes up the heading. 2nd line: Text of the question to ask. n lines: n lines of titles for each information element in the DIRECTRY.Dxx file. Lines should not exceed 126 characters in length. The size of the longest title determines how many titles are put on each line for the selection menu. xx corresponds to a value of 01 to 99. Directry files need not be in sequential order: 5, 19, 37, 88 or 1, 2, 3, 4 are OK. See the menu commands for information on setting it up in a menu. For LENGTH files, the only real way to determine the lengths is by trial and error. But file lengths are usually correct (the length of the text when it is in its own file). For title (.Txx) files, using a max title width of 20 will get you 3 entries per line. When called, the list of titles will be displayed, a selection made, and the information corresponding to that selection/title will be shown. The whole system is designed for you to create whatever DIRECTRY's you want--up to 99 of them. I have included samples of each type. Use HEADER if you want the BBS logo header line to be displayed over each data item. Use NOHEADER if you do not want anything displayed over the data item (usually implies the data item will handle it). Anything else besides HEADER or NOHEADER will be displayed over the data item. You can use SendTT ("") codes in the data text. Just use a text editor to create/modify the .Txx and .Dxx files, then just restart the BBS--the .Ixx files are built/updated automatically. See also: DirV, SendTT USER HELP My setup is designed to give users help by files. Such as the BBS Information file and the Additional Information file. However, another method is available: using a BLOCK Directry. In which each block represents a different topic. I have no example set up--but it is similar to the Unprotect Directry. It is a way of putting all your information into one place, including information about you, the system, your rules, uploading/downloading, help using the BBS, etc. For instance, this would be an exact alternative to using a lot of messages to give this information. Indeed, a Directry labeled: "Frequently Asked Questions" would probably be useful. THE "WHO'S ON" Below each menu ANSI, the console will see a user status STATUS LINE line. It looks something like this: User Name--Location 5sl 10calls 2msgs ctn Which breaks down as: "User Name" is just that, the callers name. "Location" is the callers city and state. If flashing, then this is the text they typed for a chat request. "5sl" is the callers security level value ("5") based on their current (or temporary) grouping. Example: if you an SL range of 5 to 9, and this user has 7, it will still show 5. It is done this way so you can see the effects of your <home>/<end> efforts. "10calls" is the number of times the caller has called. "2msgs" is the number of messages the caller has ever posted ("2"). "c" appears if chat trap-to-file is on. "t" appears if trap all to file is on. "n" appears if sysop-on-next is on. "PR" appears if the user is undergoing Peer Review. A music symbol when you are allowing users to try to chat with you. Other information that appears: "+5'd" after you just increased their session time by 5 minutes. "-5'd" after you just decreased their session time by 5 minutes. "SL+" after you just increased their SL by 1 level. "SL-" after you just decreased their SL by 1 level. "SL^" when you have reached the maximum SL. "SL_" when you have reached the minimum SL. VOTING The voting questions are contained in the VOTE.TXT. This file is structured as follows: Number: total number of questions Text: line 1 ┐ Text: to line n: question text │ a Number: total number of options (x) │ single Text: line 1 │ question Text: to line x: options text ┘ Text: line 1 ┐ Text: to line n: question text │ a Number: total number of options (x) │ single Text: line 1 │ question Text: to line x: options text ┘ Text: line 1 ┐ Text: to line n: question text │ ... etc. Or to simplify: n <- Total number of questions. Text Q1 Line1 <- Question 1, can be up to 14 lines. Text Q1 Line2 3 <- Number of options for question 1. Option1 <- Each option. Can have up to 7. Option2 Option3 Text Q2 Line1 <- Question 3, can be up to 14 lines. Text Q2 Line2 4 <- Number of options for question 3. Option1 <- Each option. Can have up to 7. Option2 Option3 Option4 Text Q3 Line1 <- Question 3 on, same as before. etc. Example: 2 <-number of questions. Do you like furry animals? <-question #1 3 <-number of options. Yes <-option 1/3 No <-option 2/3 Yes when they are in a zoo. <-option 3/3 Do you like the great outdoors? <-question #2 4 <-number of options. Yes, I visit them a lot. <-option 1/4 Yes, I have a garden. <-option 2/4 Yes, I have a plant at the office. <-option 3/4 No, burn it down. <-option 4/4 While you may only have a maximum of 7 of your own options for a user to select from, the software also provides an "Other" and "No Opinion" (the default) options for each question. When a user chooses "other" (the final voting question option), they are prompted to enter text describing what they mean. This can sometimes be a simple option you neglected to include, or a whole complex belief idea. this text is then sent to the sysop as a message from the AI. You may then use their answer to decide if the voting options need more options. The "No Opinion" option is the same as not voting--and will result in the question repeatedly coming up (next call) if the voting is is being done at login. Because it is not considered a real vote, the "No Opinion" selections are not graphed either. When an option's text runs into the graph, you will need to shorten the option's text. The graph shows all options except "No Opinion". The graph automatically re-size's itself between 50% and 100%--to maximize graphic variability. PSEUDO-AI The Pseudo-AI can only send private messages (E-Mail) in and out of the Private Mail base, number 001. Any messages redirected from the AI to the sysop go to the sysop--not the message-op of message base 001. I pretty much assume you will set the message-op of area 001 (Private Mail) to your name. You should not try to relocate the private mail/e-mail/whatever from area 001 to another number. ACCOUNT VALUE Accounts do have value. The harder they are to get, the more value they have. Simple higher SL values increase their value. Adding Peer Review increases the value of all passed accounts. Adding other requirements, such as name verification (users send in proof of their name) or phone verification (call back testing), further adds value. Finally, stats are seen by all--so if a user has a lot of UL credits, that account has worth. What does this mean. It means you could have troubles as accounts increase in value. More hacking attempts. Users selling, or trading accounts. Probably other stuff I have not thought of. LIFE & DEATH There are many aspects to this capability, as it has many DELETE requirements and conditions that must be met to both implement it and for a user to use it. To implement it: Set the toggle to allow it to ON. In "Change Settings", set a minimum amount of drive space before this becomes active, and set a minimum user SL value who may use it. In your menus, have an entry for "Asst" (usually in your login loop). Use an "ifSL" entry to give it the same SL value as we do in Change Settings. To remove it: Set the toggle to allow it to OFF. Remove the "Asst" menu entry. Every thing is individual. "Asst" will display the AI help request to anybody, which is why we set the SL field in the menu command itself. When using the L&D system, any user may attempt to delete it--which is why there is a Change Settings SL value. That user could do it at any time, which is why there is a "only if less than this amount of drive space" Change Settings field. It is complex because it needs to be. This capability allows users to delete files from your download directories. So you must be able to define who can delete and when they can do it. The way it is currently configured, just set the appropriate Toggle to on to implement it with my defaults. Which are SL value of at least 10 to do and must be less than one meg of available upload space to do. FILE When shelling to DOS--any changes you make in the text files MANAGEMENT (such as BLOCKS/LINES/SHORT/etc.) either will not take effect, will screw something up, or will crash the BBS. Only after exiting the BBS, or full-dooring from the BBS, should you then mess around with the BBS files. This is because upon return the software will "know" which files you altered. Whereas with shelling or shrinking, speed is considered to be the important ability, so no "file management" is done. This includes the deletion of downloadable programs. While it should not cause any trouble--why take the risk. Just use <alt>r from the waiting-for-caller screen to remove a file from the downloads areas (that is, do not do it when dooring, after you have exited you can do whatever you like). None of the dooring types recheck your file areas, or user and messages files, as well as restarting the BBS itself does. DOORS A door program is any program you temporarily pass control too. Some doors do not use the door system: DSZ, PKZIP, etc. Usually the door system is reserved for programs which also communicate out the comm port. Although the door system is also a convenience for defining programs to exit to for the sysop. Defining Use "Door Maintenance" from the Configuration menu to add additional doors to the menu options, or to modify current doors. Door definitions contain the following fields: Access start time Access end time Access to this door is allowed between, and including, the time supplied here. If the two values are equal, then access to the door is allowed during all 24 hours. Maximum time allowed in door The maximum amount of time a user is allowed in the door per door access. The door handles this, so it is by no means guaranteed. Use some high number (like 999) for unlimited access time. If the user's "time left today" is less than this amount, then their "time left today" amount is used instead. A zero value will still execute the door (it is always the door's responsibility to guard the time) but if it is handled properly by the door program, they will not be able to use the door program. Logging type 0 = none 9 = everything the door program has 1 to 8 are somewhere in between (door program defines, you should look at the door program's documentation to see if it supports this capability). Minimum drive space needed The minimum drive space (in bytes) that the door needs on the drive to run. Usually this will be very small. If you want to use 0, you should be sure the door program updates no files (including the door-exit files). 2048 will be fine for most doors, but some may need a lot more if they need to update large data files (example, a daily packing would need at least a megabyte--probably 2 or 3). So it varies widely, which is why this field is here--the door program will not be run if there is not at least this amount of drive space. Door-Op Who is the door-sysop for this door. Only this name will get sysop treatment from the door program. Path Drive\path specification of the door program. Example: C:\BBS\DOORS or C:\BBS\DOORS\ or E:\ etc. It should contain the path of the door programs' files. This field is the drive that is checked to determine that there is enough space. If empty, no space checking is done. Execution Filename and command line to execute the door. If your door program is at C:\BBS\DOORS\ABC.EXE you would put C:\BBS\DOORS\ above and ABC.EXE here. Command lines are of the form: ABC.EXE /a /k (in the future, parameters like %1 for user name will also be handled). If you know what you are doing, you could define Path to point to the door programs files, and have the door program's executable somewhere else. Example: door's files in C:\BBS\DOORS but door program at E:\ABC.EXE. You would put "C:\BBS\DOORS" in Path and "E:\ABC.EXE" in execution. Note, however, this will most likely only work if the door program has a configuration file in which you tell it where it can find its files--otherwise it will assume they are at E:\ with the executable. The following "%" macros are expanded when found in the execution line: %B Baud rate (2400, 4800, 9600, 14400, 19200, 38600) of user. %D Path to current door's directory. %N Node (1..n) being used. %L Transfer pathnames file to use (usually FNAMES.CTL). %P Comm port (1..n) being used. %S BBS's locked baud rate (2400, 19200). %U Path to currently selected file area. Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1" (if comm port = 1 of course). That is, no leading or trailing spaces are added. These codes are the same as used by protocol execution lines. Calling To call a door program, you use the "DOOR" menu command. This command is of the form: DOOR _EXITTYPE _FILETYPE _xxx Where "xxx" is a number from 001 to 999 corresponding to the record number in your Doors database. Where "EXITTYPE" is the type of exit from the BBS you wish to do. This field is optional. Where "FILETYPE" is the type of door-exit information file you wish to produce for the door program. This field is also optional. There are 3 types of EXITTYPE: _shell This is the quickest of the three methods. Fast at exiting and fast at returning. It simply shells to DOS and runs the program. Its limitation is that only the currently available RAM can be used by the program. So it is not for really large door programs. It is the method the software uses for such things as protocols and archivers. Preferred method for all door programs. _shrink This is the middle-ground of the three commands. It swaps the program to disk, runs the door program, then re-loads the program again. So you have delays when exiting and returning. The advantage is that you have full memory available for your door program. The delays are not significant. This is the recommended method for large door programs. The software first checks to make sure at least 400k of drive space is available before allowing the door program to be run. _full This method is the odd-ball of the three commands. It is as quick as shelling to exit, but as slow as the total delay for shrinking upon return. It first completely exits the program, runs the door program, then completely returns (the user is kept on-line). It gives your door program full memory usage. There are 7 type of FILETYPE: _doorinfo This produces a DORINFOx.DEF door-exit file. Also known as "RBBS" type file. _doorsys This produces a DOOR.SYS door-exit file. Also known as "Gap" type file. _wwiv This produces a CHAIN.TXT door-exit file. Also known as "WWIV" type file. _spitfire This produces a SFDOORS.DAT door-exit file. Also known as "SpitFire" type file. _pcb12 This produces a PCBOARD.SYS door-exit file. Also known as "PC-Board 12.x" type file. _pcb14 This produces a PCBOARD.SYS door-exit file. Also known as "PC-Board 14.x" type file. _wildcat This produces a CALLINFO.BBS door-exit file. Also known as "WildCat! 2.x" type file. See TECHDOCS.DOC if you want detailed information about the door-exit files. Upon exit to a door, a JDRBBSxx.DEF exit-information file is created in the directory defined in Path (see Defining). See also: FILE MANAGEMENT Executing The door program is executed when a user selects the hot-key (you defined) from the menu (you defined) for the door (you defined). What occurs (???'s are replaced by node number, eg. 001): DOOR???.BAT is created. It contains: d: CD \path execute C: CD \BBS BBS???.BAT "d:" is from the door Path field. "\path" is from the door Path field. "execute" is the door Execute field. "C:" comes from PATHS.DAT. "\BBS" comes from PATHS.DAT. "BBS???.BAT" comes from PATHS.DAT. BBS???.BAT contains: @ECHO OFF SHROOM @SHROOM.YES JDRBBS.EXE DOOR???.BAT You can see how it works. You typed BBS001, which ran BBS001.BAT, to start the software. At that time, DOOR???.BAT contained just a REMark line. Now DOOR???.BAT is given something, so that when we exit, it changes to the appropriate directory, runs the program, and returns back and re-runs BBS???.BAT. Upon return, the software checks DOOR???.BAT, finds that we are returning from a door, and acts accordingly. It also resets DOOR???.BAT to contain just a REMark--so that we exit the program in the future. The above DOOR???.BAT file might look familiar. Most doors come with a batch file that looks something like so: COPY door-exit file to door directory CD to door directory run door program CD to BBS directory Ignore these! The BBS handles all the movement/etc. Just specify the door directory in the Path field, and the door program execution line in Execution field, and it will work fine. Let me re-iterate this. You define the door program to run-- you could define a door batch file, but not normally--the software creates its own batch file which moves you to the door program's directory before executing it, and returns you to the BBS's directory upon exit. This is an extremely convenient feature, and most doors go out of their way to describe a batch file for you to create--I am saying that for the most part you can ignore that hassle. For _shell and _shrink methods the batch files are not used, instead the software internally does all the same commands, and then just calls and does the "execution" line of the door. Thus, all three methods have the hassle-free door execution procedure. Time Like file transfers, time spent in doors is reduced from the Maintenance daily time available, and if need be, from minute-credits as well. A user may call a door as many times as they want. You may set a "maximum time" a user may spend in a door per session, but since a user may use the door any number of times, ultimately they are limited by their total time available. Before calling the door, the software will verify that they have time available. A door program gives minute-credits, or removes them, for reward or loss, respectively. If a door program you are installing has the ability to define the rate of exchange (example: 1 minute-credit = $100,000) then set this value such that the highest a user would ever attain (in total) does not exceed 32,000 and the lowest they ever attain (in total) is not below -32,000. Minute-credits should not casually be played around with in the doors, they should represent seriously high goals in the game. A gambling door, for example, should not use 1:1 minute-credit ratios, but rather the byte part of the exchange rate ($1,000,000 or $10,000.00). Upon return from the door, time used in the door is handled like it is handled with bidirectional transfers--if the user exceeded the time they were allowed in the door, exchanges will be done, and it is possible they could end up "borrowing" from future uploads. When a user's minute-credits reach or exceed 32,767, it will never increase. When it reaches -32,767 it will not be reduced farther. Misc. If you give a user temporarily higher security level, and they run a door, then that temporary level becomes their new, permanent, level. I have been testing some of the door programs with this software, see the file DOORS.DOC for helpful information on various door programs. To speed up the loading of doors, use PKLite or a similar utility on the .EXE and .COMs. However, if you get the message "has overlays, continue?" then do not continue--these programs, like JDRBBS.EXE itself, have internal overlays that cannot be accessed if they are compressed. When run as an event, no time checking/handling is done. Since there is no user. If you set something up wrong, the good door programs will tell you what was wrong. PROTOCOLS All download protocols must contain a "@%L"--this expands to "@C:\BBS\NODE.???\TEMPAREA\FNAMES.CTL" or whatever name you assign. All protocols must be able to do batch transfers, and accept a file containing those pathnames the caller wishes to download. The "@" is not required, some software package may prefer "&" or some other weird character. The following "%" macros are expanded when found in the execution line: %B Baud rate (2400, 4800, 9600, 14400, 19200, 38600) of user. %D Path to current door's directory. %N Node (1..n) being used. %L Transfer pathnames file to use (usually FNAMES.CTL). %P Comm port (1..n) being used. %U Path to currently selected file area. Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1" (if comm port = 1 of course). That is, no leading or trailing spaces are added. These codes are the same as used by door execution lines. The protocol database has the following fields: Defining letter This is the letter the system uses internally, and the user sees for "protocol" in their Profile, of the defined protocol. If you use two letters that are the same, you should be sure that their SL ranges do not conflict. Minimum SL needed This is the minimum SL a user needs to have before the system lets them select this protocol. Set this higher than any SL to disable this protocol. Maximum SL allowed This is the maximum SL a user needs to have before the system lets them select this protocol. Using a min SL and a max SL allows you to direct different flavors of the same protocol to different users. Example, in my set up, level 5 users do not get to do resume-later upload aborts, and so I use a DSZ line that does not save incomplete files for that security level. If this value is zero, then it is ignored. Allowing any SL once the minimum SL requirement is satisfied. Success UL letter This is the letter, when found in the log file, that declares that the upload was successful. Fail UL letter(s) These are the letters, when found in the log file, that declare the upload a failure. See Fail DL letter(s) as well. Success DL letter This is the letter, when found in the log file, that declares that the download was successful. Fail DL letter(s) These are the letters, when found in the log file, that declare the download a failure. Technical note: The following is fairly detailed, and you may not ever need it (recommend you read it only if you are having troubles detecting bad uploads): In order for the to correctly identify bad transfers, either this field must be one character, or the pass/fail determining word must be one character. Example: DSZ's pass/fail word is either "E" or "L"--one character. So you can have up to 3 characters here ("LE"). If some other protocol has "Bad" for failed transfers and "Good" for successful transfers, then you must put a "B" or "a" here, not "Bad", not "Ba", not more than one character-- because the pass/fail determining word is more than one character. To simplify: the software looks for the "Fail letters" inside the "pass/fail determining word" and looks for the "pass/fail determining word" inside the "Fail Letters". If either of these cases come up true, then the transfer is determined to have failed. This allows me to find: "L" or "E"--rather than trying to find "LE" in the pass/fail word. So, while "LE" will not be found in "E", "E" will be found in "LE". If you have "LE" and the protocol leaves multiple letters, such as "Lbad", then it will not find the "L"--since either "LE" will not be found in "Lbad" and "Lbad" will not be found in "LE". Pass/fail determining word This is the "word number" of the letter that determines whether the transfer was successful or not. The word number of the log entry. Words are defined as text having a least one space between them. Example: "A B C" has 3 words, but "A BC" has only two. If the protocol produces entries that are some times blank (rather than, say, a zero), then you cannot use it (unless the trouble occurs after the determining and pathname words). Pathname word-number This is the "word number" of the transferred pathname in the log file. The pathname need not contain a full file path. It should at least contain the file name transferred. Percentage of time to give This is the percentage of upload time (as determined from 2400 baud) that you should give in minute-credits. No time is taken off for uploading, except with bidirectional protocols. Description This is the text the user sees when selecting and using the protocol. Log file pathname This is the full path and file name of the file in which the protocol keeps the log of what happens. Upload execution This is the execution line we should use to handle uploads to the BBS. In both execution lines, you should include the full pathname of the protocol driver being used. Example, "C:\BBS\DSZ.EXE". Download execution This is the execution line we should use to handle downloads from the BBS. The very first protocol is known as the default protocol, it is given when the user's selected protocol (somehow) has no allowable match. The internal terminal program always uses the default protocol. You may reassign the default protocol by using a defining letter of "*". You must have a BiModem entry, and a Zmodem entry. BiModem execution lines must allow for the "/T" restriction (so you should not use /T with your BiModem line). EVENTS All events are done after a user logs off, or after the "Not before" time has passed when no user in on-line. Example: a 00:00:00 does not occur at 00:00:00. But at 00:00:01 if no user is on. If a user is on it will be executed after they log off. There is no forcing a user off for events, or reducing their time for an event. You can turn off an event by not giving it any days of the week. NETMAIL AND ECHOMAIL Overview What is net mail? A "net" is just a bunch of computers. "Net mail" are messages exchanged between computers. Usually each net requires a special type of net mail. That is, if a computer you wish to send mail to is not a member of the net to which you subscribe, then you cannot exchange mail. Examples of different nets range from FidoNet and InterNet to LAN nets to simple me-and-my-friends nets. Lately, there has been an effort to merge nets, and allow the exchange of messages between these nets. As well as efforts to standardize message formatting and other aspects of inter- computer communications. However, at this time I do not have the various specs, but will expand as I get the specs. This software supports the net type known as "FidoNet". FidoNet uses a three number "node ID" for each member of a network. It is organized as: Zone:Net/Node Zone means "1" for FidoNet, other numbers for other nets. JDR_BBS supports Zone's up to 32767, but most other net mail software only goes to 255--so you may want to limit your Zone number for your net when you know you will be interfacing with these other mailers. Net means a sub-net. Sub-net's are used to more efficiently and cheaply more mail and files around the net. Usually these sub-net's represent all the net members in a local area (city, part of a state, etc.). This hub is responsible for picking up mail from each member, and dropping off new mail to each member. The last field is Node. These are individual members in the sub-net. The "local address" of that member so that the sub- net coordinator (hub) can tell who is who. All three together form what is known as your "net address"-- completely unique from anyone elses. Note that standard writing of a net address is as "Zone:Net/Node", but when entering a net address in this software you may type anything for the "betweener" characters. Example: "Zone.Net.Node" works. So you do not have to remember the confusing ":/". FidoNet is the most widely used net in the PC world. It uses a specific address format and has lots Hubs which provide significant cost savings. A net mail session involves sending packets to and from another member (or hub). Packets are messages stored into a single file for transmission. To get an "official" net address, you must contact your area's hub (or somesuch) and ask them for one. You will need to get at least one net address for each zone (net) to which you wish to be a member. Different nets exist for a variety of things. NetMail NetMail is a type of message area. Messages left in this message area do not go to a bunch of addressees, but rather each message is destined for a specific address. To define a message area as NetMail, give it the NET attribute (but not the ECHO attribute). There are only two types of NetMail: private and public. However, you can create message areas that have a minimum SL requirement. This can be useful to create a private NetMail message area among sysops, for example, while also having private and public NetMail message areas for all users to use. NetMail, and EchoMail also, differ from regular messages in that they contain "hidden" lines which provides information about who and where the message was sent from--no matter where it finally ends up. NetMail can be thought of as a point-to-point mail system. You create a letter, and you want it to go to another BBS. EchoMail EchoMail is a message area type. It relies on "routing" to decide where messages are to be sent. EchoMail message areas are centered on one BBS. This is known as the originating BBS. To become a member of an echo, you must call up the originating BBS and ask to be placed on the list of BBS's receiving the echo. You need to set up a message area to receive this echo's mail. From the originating BBS, you get what is known as a "conference name" (also a "tag name"). You use this in the "EchoMail mapper" I have--connecting this name with the message area you want to receive the messages. You may reference multiple names to a single message area (combining echos--but outgoing messages will always be references as being in the first conference name for that area). You must also create this message area with the NET and ECHO attributes. The next step is routing. Use the "Outgoing EchoMail Routing" command for this. This database only has three fields: message area, net address, and last-read pointer. The message area is an EchoMail area. The net address is the net address of your originating BBS. The last-read pointer is the highest message number that that BBS has seen--it's mainly internal, so you need not worry about it. Once done, whenever a message is posted on the originating BBS, that message will then be sent to all member BBS's (of which you have become one). This is done according to a schedule the originating BBS sets up--usually based on message volume. Similarly, when you post a new message in that area, it will be sent to the originating echo BBS, which will then re-send it to all member BBS's. This you decide. If you route via your local hub, then the cost is minimal, but if you have to call long distance, than once a week might be more cost- effective. There are two flavors of EchoMail: EchoMail, and Conference Mail. EchoMail consists of a single originating BBS, and a bunch of subscribing BBS's. Sending messages can be imagined as fireworks: you launch new messages up to the originating BBS, and that BBS launches the messages out to all the subscribing BBS's (an umbrella). Conference Mail is slightly different in that all subscribing BBS's are considered originating BBS's as well. This means it is the responsibility of each BBS to send new mail to all the other BBS's--this helps distribute costs. Typically, routing files will only have a single line--that of the area's originating BBS for EchoMail. However, if you are an originating BBS, or the echo is a conference, than your routing file will have entries for all the BBS's you wish to send duplicate copies of any new mail too. The software stops re-sending of messages back to the BBS who sent them to you. So do not worry about duplicate messages. FidoNet FidoNet is the most popular PC-based net. It offers the advantage of cost savings. FidoNet requires a FidoNet address. To get one, you should talk to the sysop of BBS in your area who is getting FidoNet echo's. Ask him which BBS he should call. Then call that BBS and ask the sysop for the procedures to get a FidoNet Address. Currently, these procedures involve giving your address and voice phone number (they do not explain why). You'll also need to pay a small fee (usually under $20) per year. Once done, or not, you'll need to get your hands on the latest NODELIST.xxx file. These have a variety of names, but should be on the area coordinator's BBS. It's hefty--it'll expand out to 1.2+ megs. It contains all the other BBS's in the FidoNet network. These "member lists" are common to all nets you join--each has their own, although few exceed 20k in size. You need only unpack the node list and add an entry in your node list database referencing this new (or changed) node list. The next time the BBS is restarted, it will automatically discover it as new (or changed--such as when you edit it) and re-index it properly for the software's use. Hubs Hubs are where the great cost savings of a net come in. You route all your outgoing messages through a hub. Instead of having to call each address, usually long distance, you can call your hub, usually a local call, and they will route the messages to any other address in the world for you at no additional charge. It is the simple hub-and-spoke system. Airlines and shipping companies use this method as well. It is quite common, and very efficient. You must be a FidoNet member to use FidoNet hubs, and the messages you route through the hub must be destined for other FidoNet members. These other members can be local addresses or long distance or even international. The same is true for each other net. Hubs go through a procedure known as polling. In which you call them to get/receive new mail, or the hub calls you to drop off/check for new mail. Usually this is done each night--but any schedule is possible. For now, you should tell your hub to poll you. This is because I have a rather sophisticated polling routine in the works and it isn't ready for this release. You can use "dHUB"--but it is not fully ready yet, as it only does one calling attempt. Costs Both NetMail and EchoMail rely on the BBS that posted the message to foot the costs for actually sending the message. So, if you have a hub, then the costs will consist of the yearly fee, and any local charges to call the hub. If you do not have a hub, you will have to pay the costs to call the BBS's yourself. The good thing about this is you do not have to do it everyday for every echo. You can do it, for example, once a week, and you only need to do it when you have mail to send. If you wish to have an EchoMail area, and you do not have access to a hub, you should specify that those that want to receive your echo should call you ("to poll you"). If you have a hub to access, then it is easier to just send mail out to them. Misc. The software does not use NODEDIFF files (which your hub can supply) to update the node list. It instead relies on you copying the whole new list over the old list. However, you may do "quicky" updates (adding an address or few) by creating a separate net list containing these new addresses (just remember to have the Zone and Host lines proper). After a NetMail message has been successfully sent, it has a SENT flag set--so it will not be re-sent. You can alter this flag by editing the message's header information. If an EchoMail packet accidentally got deleted by the receiving BBS, or whatever, you can just change the "last- message-seen" pointers in the routing entry for that address to have the messages re-sent next time. Whenever an exchange of mail occurs, both mail you wish to send, and mail waiting for you, are exchanged. That is, you do not have to call once to drop off, and again to pick up. Messages are given the date/time of when they arrive to the BBS--not the date/time when the message was created on another BBS. Same for message numbers. Messages are given the next message number in your message areas--not the message number used by the originating BBS. If you run out of drive space when importing messages, the .PKT will be moved to your \BBS directory. It will remain here and await for you to import it manually when you have enough drive. Manual import can be done by specifying the .PKT file's pathname when entering messages with the Upload (import) option ON. Commands There are 3 basic commands to handle net mail: NETa To contact all members of an EchoMail area and attempt to exchange mail with them. Long Distance charges would add up quickly were you to use this. It is mainly for local or private nets. It makes one attempt at each address. If contact is made, then all messages in all areas destined for that address are sent. So while it uses a message area to decide which addresses to call, it will send that address any mail in any area they have waiting. <end> This is the key you may press after you call a BBS. This command will send any new messages meant for the BBS. If you used "d string" to dial, then it will use the net address in your sysop's database--otherwise it will ask you which address to use. Unless you belong to a hub, this is the command you will probably most use. If an EchoMail area only routes to the originating BBS, then NETa is like an event version of this command. Some mailers will require that you wait until the BBS's (that you called) is no longer sending anything--if you are having troubles by hitting <end> right away, or while something is displaying, then wait until the display stops. How many messages you can send with the <end> command relies on two factors: your computer's speed, and the wait the called computer is willing to endure. Usually, the limit is whatever your computer can pack in thirty seconds. dHUB This command will make a single attempt to call your hub. If successful, it will drop off any new messages to addresses which have mail coming and have the same zone as the hub. This is the preferred command to exchange mail, if your hub cannot poll you. Unfortunately, at the last minute, I noticed a problem: multiple nets mean multiple hubs and multiple net addresses for you. My mistake. However for now Settings allows you to only define one net address for yourself, and one for your hub. There is no easy way around this. Keep the values at your main net for now, then change them and use <end> for other nets. This will be fixed next version (I'll also add AKA support). See also: MENU COMMANDS Not Ready The software cannot handle some of the net operations specific to hubs. It does not "store and re-send" packets, but creates and unpacks them when needed or received. An "intelligent" dialing system. Such as repeat-until-answer and intelligence needed when calling other nodes. AKA addresses for net nodes. Password protection schemes for net nodes. Handling of specific hours in which a BBS accepts mail. Lots of other minor stuff. Registered sysops get to do file transfers and send compressed message packets. MULTI-NODE/ With .08 the BBS is now undergoing "alpha" testing of multi- MULTITASKING node operations. By "alpha" I mean I think it'll work, but OPERATIONS those of you who want to try it--let me know what happens and what is needed still. Protocol logs need to be made "multi-node-able"--I haven't looked into it yet, but you can get around this by simply specifying the protocol log to be put in a NODE.??? area (although this doesn't solve the environment SET's that some use). Also, there as yet is no "inter-node cross-talk". That is, not only can't users talk to another user on another node, but the BBS doesn't know who's on the other node. SHARE.EXE will need to be installed for multi-node operations under MS-DOS and DesqView (not sure about Windows, or OS/2). I don't use any kind of fancy record-locking or file locking. I merely open all files in "deny none" mode, and assume DOS properly handles the job (that when you do an INT 21h to write to disk, that another INT 21h cannot be done at another node while the first one is midway though). I'll probably do inter-node stuff for the next release, and some minor testing with DesqView and declare it done. But it probably works now. One thing that should really be useful is a "sysop node"--you set up a node that nobody can contact via the phone, and just switch to that multi-task window when you want to logon. This allows you to avoid waiting to access your own BBS. Do not let users on more than one node. There is no serious checking for one node "re-working a file" and the other nodes (for instance, the sysop doing a pack files). Events will each run on each node for now. These problems will have to be knocked down one at a time. INTERNAL NETS This involves connecting computers via a null modem and using JDR_BBS as a medium on one or more of your computers. You must specify in your fossil driver line each port. For instance, I have an HST connected to COM1 and a null modem connected to COM2, and use the following CONFIG.SYS line: driver = x00.sys 2 b,0,19200 b,1,19200 r=4096 eliminate There are two ways to connect up two computers via a null modem using JDR_BBS. The first method is for when both computers are running JDR_BBS. This involves going to the waiting-for-caller screen of both computers, and selection <alt>p and changing two whatever comm port the null modems are connected to. This is a hard link, from which you can use <alt>s, <pgup>, or <pgdn> only. The second method involves JDR_BBS being on one computer run as a straight BBS, and JDR_BBS on the other computer in <alt>d. For both computers, you will need to first use <alt>a to set the comm port to your null modem--you will need to repeat this step when you are done. This allows you to use all the <alt>d commands. You can mix and match the above, <alt>p, <alt>d, <alt>a, it does not really matter. What matters is that you get both computers pointing to your null modem. It might be more convenient to set up multi-tasked "sysop nodes" on each computer already pre-configured as a null modem connection. Giving it no timer ticks until you need it. FILE With all the I/O being done, it is inevitable that you are CORRUPTION going to get some sort of file corruption. Executing a: CHKDSK /F will fix these problems. However, CHKDSK may fix it by increasing a files size (particularly for allocation errors). For text files this is not a problem. For the USERS, FILELIST, and MESSAGES.HDR, you should run the appropriate integrity testing command. For other .DAT files, you can use their Databaser menu command to edit them to find any visible problems. If you have Trap All ON, and shell to DOS and delete the SESSION.LOG file, you most likely will get a fatal "sector not found on drive d:" and have to reboot the system. This occurs because I do not close my files when shelling to DOS. The reason I do not close them is because <alt>s could be hit anywhere, and I have no way of knowing which files are open. DOS does not like you deleting its opened files. If any of the .IDX index files become corrupt, just delete them and restart the BBS, they will then be recreated (you should restart all nodes). You can tell the users index, for example, is corrupt if you are not allowed to enter what you know to be a valid user's name, or if the data returned about an account is wrong, or that of another user. TROUBLE- If you crashed you BBS while in a door program, you should SHOOTING delete the DOOR???.BAT file. If you do not, then every time you try to exit the BBS, it just runs this batch file thinking a door is being run (this occurs until you successfully return from a door if you do not delete it). If you are testing door programs, or trying to track down something in one of the door exit files (DORINFOx.DEF, etc.), then just run JDRBBS.EXE (not BBS???.BAT)--after you select to exit the BBS to a door, the system shuts down (because it could not run the DOOR???.BAT file from BBS???.BAT), allowing you to look at the door exit files, or test door programs using the same door exit files. "Device I/O" errors usually means you have specified a pathname that cannot be found, or cannot exist. "String space corrupt" is a programming error--and if you can duplicate it consistently, please tell me, as these errors usually occur a while after the actual bug itself. So are very difficult to track down. "Cannot execute filename" is an error that appears when you run a door program in _shell method, and the program needs more RAM (so run it in _shrink or _full method). If when you restart the BBS and it does not clear the screen and display the copyright when loading the indexes--then it is due to you loading a TSR that uses up too much memory. If the software does not record in the callers log the data from protocol log files, or the software does not recognize file transfers, then this is due to you not properly telling the software where it can find that protocols log. If the software does not record in the callers log the data from net mail transfers, or does immediate hanging-up after sending or receiving a packet, then you should make sure that the DSZ protocol log pathname (see PATHNAMES) is correct. PERFORMANCE Anything you can put into a RAM disk will speed things up. ENHANCEMENTS Doing a weekly packing will also improve overall performance. A disk cache might improve performance--has not been tested. It might be better to use the memory for a RAM disk. A disk cache that knows the difference between a RAM disk and a hard disk (and only caches the hard disk) would be useful. Using NU's SpeedDisk or some other disk defragmenter really helps--BBS's are a natural fragmenter of files--I recommend once a week. Both the packing and defragmentation can be done as an event. For the defragmenter, just set it up as a full-exit door. If your BBS computer will only be for the BBS, I recommend you put the following into a RAM disk: File 640k 1MB 2+ MB LINES.$$$ √ √ √ FX.TXT √ √ √ CMDS.DAT √ √ MENUS.DAT √ √ BBS_CMDS.DAT √ √ most used .ANS's √ √ USERS.IDX √ √ FILES.IDX √ √ JDRBBS.EXE √ 640k, 1MB, and 2+ MB are how much available RAM you have. MENUS.DAT, BBS_CMDS.DAT, and CMDS.DAT are part of the menu system. You should not put these into RAMDRIVE until you are fairly sure you do not want to make any more menu changes. Because McEditor will change these files--and if they are on your RAM drive, then the changes are not copied back to your hard drive. Putting the .IDX's above in a RAM drive means they will be deleted when you reboot the computer. This is no problem, since the software will just rebuild them right back up. So it is practical to keep the .IDX's on a RAM disk--and if you keep auto-name-detect and auto-filename-detect ON, then I would recommend you put USERS.IDX and FILES.IDX on the RAM disk. Remember that files in \RAMDRIVE are automatically updated to the RAM disk whenever you change them. So there is no need for you to copy files to your RAM disk yourself. If you really want to put files that get updated onto your RAM disk, I would recommend you put a line to copy these files back to your hard disk in your BBSxxx.BAT file after JDRBBS.EXE is run. In general, the software has been designed to be very flexible. Allowing you to decide on the best allocation of your resources. While putting LINES.TXT onto a RAM drive and defragmenting will speed things up--that is not the main reason to do so. The main goal is to reduce wear and tear on your hard disk by doing so. REGISTERED Besides the stuff in ORDER.FRM, Registering will get you a PACKAGE modified/complete version of JDRBBS.EXE which includes the things below. The purpose of the registered package is not to cripple the operations of the BBS, or penalize the users. It provides enhancements that a sysop would like. Since, ultimately, it is the sysop who registers this. You are also limited to like 2000 active users and 2900 active files. Whereas the registered package boosts these numbers at least into the 20,000's. DataBaser You get the source code for this module. Net Mail File The capability to do netmail file transfers is also separate Transfers from the unregistered version. The registered package includes the necessary module to allow you do and handle file requests. It is required if you want to send compressed messages--which results in reducing by half the packet/messages transfer time over the phone lines. This feature both saves money and time. It is also quite nice to set up a file exchange net with your fellow sysops (just like net mail, but with whatever new files are put into a specified area(s)). Sysops This is a collection of routines not included with this Package version. Most new sysop routines will be going here. These are all sysop enhancements--none for the users. The following additional menu routines are included with the sysop package: Alter L&D --Alter L&D/File Point values globally per area. Directory --Lists the contents of any directory in DOS style two column form. DL Potential --Lists users by security level, including information about their "bytes can download" and minute-credits availability. File Lists Comparer --Will compare two lists of file names and descriptions (from other BBS's lists or Master Lists) and produce a third list of files that are common, different, or unique using the two lists. File Spell Checker --Will check the spelling of all words in a text file, putting all not-found words into a file. Fix User SL's --Allows you to change all user security levels from one value to another. Global File Area SL changer --Allows you to change many file area SL limitors at the same time. Pack Files --Does the purging of deleted records from the data files. Put here because a sysop who uses the BBS for less than 30 days has no need to pack so soon. If you do not pack your data files, they will continue to grow ever larger, and eventually the bloat will slow the BBS down noticeably. Post Upload Processor --Allows you to run files that are on-line through the same post-upload procedures that uploads go through. Including comment header and virus checking stuff. Print Out Messages --Print out all the messages in a message area to a file. Includes deleted messages. Strip ANSI & Avatar --Will selectively strip ANSI and Avatar codes out of any file. Vote Summary --Summarizes the voting results in tabular form. The following capabilities are turned ON with the registered package: Add Comments --To automatically insert your BBS's comments into the header of ZIP or ARJ uploads. Extract Comments --To automatically extract ZIP header comments out of uploads and save them to a text file (so you, and/or your users, can know more about the BBS's from which the files came). Import .DIZ descriptions --To automatically insert a .DIZ description file from an upload and place it into your file reviews. NEXT MENUCMDS should be your next stop.